Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/snmpv2/snmpv2-minutes-92oct.txt

Text File | 1993-02-17 | 39.9 KB | 1,032 lines

Editor's Note: Minutes received 12/9/92

INTERIM_MEETING_REPORT_

Reported by James Davin/Bellcore

Minutes of the SNMP Version 2 Working Group (SNMPV2)

The SNMPV2 Working Group met October 5-6, 1992 in Knoxville, TN. The
Chair, Bob Stewart, called the meeting to order at 9:05 AM and
circulated the attendance roster.

Agenda


   o Introductions and Housekeeping
   o Goals and Process

      -  Credo
      -  Organization
      -  Stepwise Refinement to SNMP

   o Easy Questions
   o Proposals
   o Summary


Introductions and Housekeeping

All present introduced themselves.  The schedule for lunch and breaks
was established.  Changes to the Agenda were entertained.  Local
arrangements for reading email were explained.

Goals and Process

Bob presented some slides outlining his vision of where the Group was
going and how it would get there.  Under the rubric ``Goals and
Process,'' Bob introduced three topics:


  1. Credo:  As a ``credo'' for our collective work, Bob quoted a recent
     email statement by Dave Perkins as an illustration of the spirit he
     hoped everyone would bring to the discussion:

         ``to assist with creating a positive and long lasting
         solution for the community.  This goal comes before any
         personal or company goals which I set aside when I
         communicate via EMAIL and attend IETF functions.''


  2. Organization:  Bob noted that the Working Group was a chartered
     IETF Working Group.  James ``Chuck'' Davin was appointed to take
     Minutes for this meeting.  Bob stated that the Working Group would
     make decisions by discussion and consensus, both in meetings and

                                   1





   via email. Marshall Rose was appointed editor of the Working Group documents.
   Bob noted that the Group would rely on Marshall to make appropriate
   changes without detailed instructions, except in those cases where
   ``le mot juste'' was required to capture the consensus properly.
   It was agreed that Marshall would clearly indicate all changes to
   the Working Group documents by change bars.  A question was raised
   about whether the change bars should indicate differences from the
   originally posted documents or the most recent document versions.
   This question was deferred, because, at the moment, the latest
   version is the original posting.

   It was noted that the Working Group Minutes would be available
   on-line in the usual IETF repositories.

3. Stepwise Refinement to SNMP: Bob explained what he meant by
   ``Stepwise Refinement of SNMP'' by presenting a slide with the
   following points:

     o Assume that SNMP is basically sound.
     o Widespread implementation.
     o Current level of technology, cooperation, understanding.
     o Choose improvements.
     o Maintain first principles.
     o High benefit-to-cost ratio.

   Bob identified the SMP proposal as the baseline documents from
   which the Working Group would proceed.  He noted that there were 8
   documents, and 4 implementations; these latter are to be regarded
   as supporting the Working Group and building confidence in its
   baseline; the implementations will not in any way constrain the
   decisions or directions of the Group.

   At this point, Marshall said that all four of the SMP proponents
   look forward to making implementation changes based on the work of
   the Group.

   Bob next noted the need to coordinate with the SNMP Security
   Working Group.  He noted the pledge of timely cooperation by the
   relevant Area Directors at the Cambridge IETF meeting.  He noted
   that the liaison function is neatly realized insofar as Keith
   McCloghrie is both one of the SMP proponents and the co-Chair of
   the SNMP Security Working Group.  Bob concluded by saying that,
   although the Group would not delve deeply into security issues, it
   could not and would not ignore them completely.

   Bob identified the ``deliverables'' of the Group as a set of
   Internet-Drafts, revised according to the judgement of the Group,
   together with a recommendation to the IESG that these documents
   (possibly together with revised documents produced by the SNMP
   Security Working Group) define the next generation SNMP framework.
   Bob said that, assuming our ultimate agreement, the recommendation
   of the Group would be for Proposed Standard status for these

                                 2





     documents. Bob said that the schedule goal of the Group would be to finish
     up and, consistent with its Charter, to ``drop dead'' in the Spring of
     1993 (shortly following the IETF plenary meeting, March 28 - April
     2, 1993, in Columbus).  A discussion of the schedule goal ensued:
     Marshall and Jeff Case emphasized the need for quick progress; Dave
     emphasized that haste should in no way compromise the openness of
     the process; Chuck emphasized that haste should not compromise the
     quality or thoroughness of the solution, because it is unlikely
     that revision of the standard framework will be undertaken again
     soon.  The Group agreed that its schedule and pace must be governed
     by all of these considerations.  Recognizing considerable consensus,
     currentt and from the Cambridge BOF, that the work should be completed in
     December, the Group deferred accepting that as possible for the end of
     the secong day.


Easy Questions

The focus of the Group turned to what Bob had identified as ``Easy
Questions.''  In this part of the meeting, Bob encouraged people to
raise what they regarded as ``easy issues'' about the proposed
framework.  Those that could be quickly resolved, would be dispatched in
real time.  Those that proved more complicated would be noted for later
consideration by the Group.

Tracy Cox raised the question of whether or not the row-set-and-create
mechanisms currently specified would be mandatory.  Jeff suggested that
it should be mandatory for new MIBs.  Tracy sketched some scenarios in
which the specified mechanism was undesirable owing to time delays
between the processing of a SET request and the actual effecting of the
requested alteration.  The Group agreed that this point was not simple
and warranted further discussion.  Tracy accepted an action item to
present more detail and analysis of the relevant scenarios and propose a
solution.

Satish Joshi asked whether or not the SMUX should be part of the
standard framework.  Marshall said that the SMUX is not part of the
framework, but elements in the current proposal (the ``or'' table in the
SMP MIB) permit the use of SMUX or SMUX-like mechanisms.

Chuck expressed a general concern about uncertain conformance
requirements and raised the particular question of whether or not use of
the AGENT-CAPABILITIES macro would be required of conformant
implementations.  Chuck proposed that the specification language be
clarified to either make the macro a requirement or to omit it from the
standard framework (as is now the case).  Keith says that use of the
CAPABILITIES macro would be required because of its relationship to the
``or'' table in the proposed MIB. Marshall argued that use of the macro
should not be required because it was not relevant to all of the
constituencies of the proposal:  it includes vendor tools, user tools,
and Working Group tools.  Chuck said that the different requirements in
each of these three contexts should be written down unequivocally.  Jon

                                   3





Saperia said that he favored requiring the AGENT-CAPABILITIES macro
mandatory.  After some discussion, it was proposed that the word
``should'' be applied to this issue.  Chuck said that he found the use
of ``should'' acceptable only if no other parts of the framework
depended for their function or their unambiguous definition on the
presence or use of this macro.  The Working Group agreed to using
``should'' provided that this condition was met.

Dave suggested that a list of ``required reading'' be prepared to help
give everyone a common context for discussion.  The Group agreed, and
Dave accepted an action item to produce this list for inclusion in these
Minutes (see attached).

Dave also proposed that the new standards documents include a glossary
of key terms.  It was suggested that Marshall undertake this task and
include the glossary in the introductory document.  The Group agreed
that Marshall would consider the effort involved and report back after
lunch.

Dave suggested that the Group prepare a detailed analysis of how well
the baseline proposals addressed the concerns raised at the Atlanta IETF
session on perceived deficiencies in SNMP. Jeff said that the basis of
the current proposals was a list of problems he had maintained since
1988 that included the IETF session, a previous INTEROP BOF, and some
additional items as well.  Marshall said that preparing such an analysis
would be too much effort.  Jeff elaborated, saying that each item on the
list was evaluated according to several criteria (e.g., compatibility
with installed base, performance, impact in existing MIB object access
methods).

Peter Wilson raised the question of party proliferation.  After brief
discussion, this was identified as an issue for the SNMP Security
Working Group, and further discussion of this topic was deferred for
later in this meeting.

Dave suggested that the Group consider a revision of the MIB-2
interfaces table.  The consensus of the Group was that this was not in
the scope of its Charter as it could be handled in the normal course of
IETF business.  The Group agreed to a recommendation that this work be
pursued soon after the SNMP evolution work is completed.

Dave raised a question about the definition of sysObjectId.  It is
ambiguous, but is also used by SNMP 2.  Steve Waldbusser said that
sysObjectId should identify the combination of software and hardware
that makes up the managed system.  Jeff agreed with Steve, and described
various strategies used by OEM software vendors to address this
question.  Marshall said that the actual definition of sysObjectId is
not ambiguous, but that the example text that follows it is bad.

SMP assumes that sysObjectId names a protocol/MIB implementation but
(not necessarily) the type of box (e.g., a bridge, router, etc.).  Are
we comfortable with this assumption?  Do we want to legislate rules for
assigning sysObjectId?


                                   4





Proposal:  either fix the ``or'' table so that it doesn't refer to the
(arguably ambiguous) sysObjectId or else define a new MIB table that
tells what MIB objects are supported.  Action (Dave):  prepare a
proposal if needed.  If the Group agrees that the interpretation of
sysObjectId that is implicit in the baseline proposals is correct, then
this consensus must be documented in the standard.

After lunch, Bob suggested that the Group change its discussion mode to
focus on brief discussions that would either result in quick resolution
of topics or place those topics on a ``deferred issues list'' (see
attached) for later discussion.

There was a discussion of how Working Group consensus should be
achieved, whether email or face-to-face meetings would dominate.  Bob
explained that neither would dominate.  He would attempt to assure
progress by posing straw conclusions and calls for consensus by
requesting strong objections, but ultimately the Group would be governed
by the soft principles that have been traditional in the IETF.

Proposals

The remainder of the day was spent in considering various proposals for
amendment of the baseline documents.

Bob presented the list of pending proposals collected from the mailing
list:


   o Reliable Traps - Chuck Wegrzyn
   o Party Proliferation - Pete Wilson
   o Remove Counter64 Time Limit - Pete Wilson
   o NAME Clause - Pete Wilson
   o OID Optimization - Ilan Raab
   o Redefinition of ``Manager'' - Bob Stewart
   o Date and Time Textual Convention - Jon Saperia


He asked the Group for others and added:


   o Miscellaneous changes from Jeff Case.
   o Miscellaneous changes from Chuck Davin.
   o Miscellaneous SMI changes from Dave Perkins.
   o Ideas on Get Bulk OID compression from Satish Joshi.
   o Two ideas from Robert Snyder.

      -  Identifying MIB objects with constant values.
      -  Contents of Set Responses.


   o Get Bulk OID Compression:  Satish spoke about his ideas on Bulk
     Retrieval.  He suggested compressing the OIDs in the varbind list
     of responses to Bulk Retrieval requests.  He observed that the OIDs

                                   5





  in the 2nd and subsequent repetitions in a response could be
  abbreviated.  Compression could occur in the context of the
  original request or in the context of the preceding varbind.
  Satish noted that this scheme presents no compatibility problem
  because existing agents don't implement the new Get Bulk operation.
  General question:  is it worth it?  Marshall said that there are
  easier ways to save OID bytes.

  Jeff observed that we hate the byte-skimping of the ASN BER, and
  asked why we would want to repeat that mistake.  He also noted that
  a growing number of MIB tables are indexed by OID values, and so
  the savings in those cases would be minimal.

  Satish said that retrieval of very large tables (e.g., an RMON
  traffic table with 10000 entries, a bridge table with 8000 entries,
  or a Token Ring table with 4000 entries) would benefit
  significantly from this strategy, even if the savings for smaller
  tables were somewhat less.

  The Group agreed that Satish and others should perform some real
  measurements that include the CPU costs (as well as the bandwidth
  savings) of this approach.

  It was noted that compressed OIDs could not really be encoded with
  ASN.1 OID Tags and would have to be transmitted using an additional
  ASN.1 type.

o NAME Clause:  Peter Wilson led a discussion for about 30 minutes on
  the addition of a NAME clause to the OBJECT TYPE macro.  Cheryl
  agreed with the proposal, but thought that the length of any such
  field should be less than 15 bytes.  Bob suggested that it be
  called a LABEL clause, not NAME clause, to better reflect its true
  nature.  Ken Key raised the issue of what language the LABEL
  information should be in.  Dave P. suggested that information that
  is primarily an aid for management stations should be in separate
  documents.  Chuck echoed Dave's suggestion, recalling his earlier
  suggestions to cleave the framework in this way.

  The Group concluded that the NAME clause should not be introduced
  because one could get the same effect by well-chosen object
  descriptors.  However, it was also agreed that this sort of
  information might be included in macros exclusively for management
  stations.  Dave Perkins accepted an action item to explore the
  feasibility of such a notation.

  Peter Wilson then offered a proposal that the time limit associated
  with the use of the 64-bit counter type be excised from the
  baseline documents.

  A router implementor argued against the proposal, arguing that
  critical code paths can't afford lots of double precision math.
  Cheryl found the time limit desirable, given MS polling
  requirements.

  Jeff spoke of hardware barriers (e.g., need to lock the bus) that

                                6





     make broad implementation of 64-bit counters difficult.

     Peter argued a broad need for big counters in hierarchical
     management systems (bigger numbers at higher levels in the
     hierarchy).

     Marshall noted that aggregation counts at the higher levels are
     semantically different from the raw ``leaf'' counts on which they
     are based.

     Keith followed this by saying that we need appropriate MIBs to do
     effective hierarchical management and limit the proliferation of
     64-bit counters.

     Steve Waldbusser noted that effective MS support for 64-bit
     counters may be a long time coming.

     Wilson noted that constraining the use of big counters might limit
     the effective lifetime of the new framework.

     Dave noted the role of big counters in the work of IEEE.
     The consensus of the Group was to leave the restriction as it is.

   o New Textual Convention:  the Group took up Jon Saperia's proposal
     for a new Textual Convention for expressing dates.  The Group spent
     some time tweaking the details of this proposal.

     Bob asked whether display hints imply leading zeros.  Keith said
     no, but there might be an ambiguity in the definition of display
     hints that needs to be fixed.

     Issue:  where is byte ordering on the network defined?  (i.e., are
     Textual Conventions that imply a byte ordering part of the
     mgr-agent contract or just a mgr aid?)

     In part to avoid the question of leading zeros, the Group agreed
     that tenths of seconds was adequate resolution for this proposal
     and abandoned microsecond resolution.

     Mike Davison suggested augmenting the display hint notation to
     provide for real field precision.

     Jon accepted an action item to post the agreed, amended proposal to
     the mailing list.

   o New MIB Object Clause:  Robert Snyder proposed a new MIB object
     clause that identifies an object as having a constant value:  a
     manager need only retrieve it once.  Marshall asked what macro it
     should go in.  Chuck suggested that this information was really
     more of a manager aid than an essential property of a MIB object.
     Robert Snyder accepted an action item to go examine some MIBs and
     report back on these questions and on the number of cases in which
     this idea would yield actual benefits.


The remainder of the day was spent reviewing a list of proposed changes
introduced by Jeff Case (see attached).  Unless otherwise noted, the

                                   7





Group accepted all of the changes on that list.

Item 1 on the list proposed that the term ``SMP'' be purged from the
documents.  The Group agreed, stipulating that the terms ``SNMP-1'' and
``SNMP-2'' be used as appropriate, instead.

Items 4 and 5 could not be quickly resolved and were deferred.

Item 11 was tentatively approved.  Davin took an action to investigate
the use of readOnly in deployed implementations.

Item 14 was agreed, but the Group stipulated that the additional
information would somehow be part of the appropriate macro(s).

Item 21 was not quickly resolved and was deferred.

Item 22 was agreed but the curly braces removed from the replacement
text.

Item 24 was tentatively agreed, but there was some reluctance to accept
so significant a change without more deliberation.

Item 26 was agreed.  Davin took an action to investigate the use of
readOnly in deployed implementations.

The first day of the meeting concluded at 17:26.

DAY 2

The Group continued its discussion beginning at 9:00 AM.

Robert Snyder raised the question of the meaning of a negative value
with type TimeInterval.  The Group agreed that a range should be added
to the definition of that type.

Bob Stewart offered a proposal that would clarify the definition of
``manager'' and ``agent'' in the framework:

A ``manager'' is any active network management component that observes
or controls one or more network devices, whether locally through
implementation-specific interfaces or remotely via SNMP, with or without
a human interface.  Such a manager may use any subset of the SNMP
manager functions.  Definition of ``agent'' is unchanged.

Jon Saperia objected to this text, arguing that we don't want to have a
``roll-your-own'' definition of a manager.  E.g., does a compliant
``manager'' need to support Sets?

Discussion of conformance issues and the question of whether a manager
requires a user interface ensued.

Two possible problems were identified with definitions of a manager:

1) Too restrictive, excludes useful products 2) Doesn't contribute much

                                   8





to collective understanding so that we have a common basis for
addressing issues (like confirmed traps in ``agents'').

E.g.:

Manager Agent master slave responsible not responsible

Bob accepted an action item to propose appropriate text, but the current
text will stand until new text is produced and agreed.  Chuck accepted
an action item to attempt a glossary.

Robert Snyder withdrew his proposal about different values in the
response to a Set request.

Bob Stewart proposed to remove varbinds from responses to Sets
altogether, citing the bandwidth savings.  Chuck seconded this idea,
citing the improved security that would result:  configuration errors
would be less likely to expose private data.

Peter Wilson and Robert Snyder opposed this change because they
preferred the option of using the varbinds in a response to a Set to
carry other information.

Marshall said (incorrectly) that the security benefits of this change
would require configuration of an additional party.

The Group agreed that responses to Set requests should remain as
currently specified in the baseline documents.

At this point (10:22 AM), the Group took a brief break.

When the Group resumed at 10:40, Dave Perkins led a discussion on a list
of proposed changes to the SMI that he prepared.

Dave actually submitted two separate lists of issues/suggested changes.
One list covered the textual conventions SMP document.  It had 10
numbered points.  The other list covered the SMI SMP document.  It had
50 numbered points.  In the 2 days at Knoxville, Dave was allocated
approximately 2-3 hrs to go over the lists.  Only 8 items from the SMI
list were covered.  Those items are included in the minutes.  The
meeting attendees were given a paper copy of the lists.  An electronic
copy is available from the archive at thumper.bellcore.com.  Dave plans
to update the lists and submit them for consideration at a future
meeting of the WG.

9) All items should include a required DESCRIPTION clause, an optional
REFERENCE clause, and a required STATUS clause.

In response to this item, Jeff asked how a COMPLIANCE or CAPABILITIES
macro could have a ``STATUS.'' Dave responded that the function of this
clause was to mark OIDs as eternally assigned but no longer
``important.''  It is a way of signaling management stations that it is
OK to forget a particular OID assignment.  The Group agreed to this
change.

                                   9





11) The SMI needs to specify conventions on things like uniqueness of
names, max length of names, allowed characters in names.

There was an extended discussion of the uniqueness and form of object
descriptors.  Dave modified his proposal to be that all the rules
governing the form of object descriptors be gathered into one place in
the document.

Dave proposed that the SMI explicitly require counter names to be plural
(not simply to end in ``s'').  The Group agreed.

Dave proposed that object descriptors have a maximum length.  The Group
agreed to the value 64.  Bob Stewart took an action to poll the mailing
list to determine if any object descriptor in any extant MIB is longer.

Dave proposed the object descriptors in standard MIBs should be unique
across all standard MIBs; that vendor MIBs should be encouraged to
preserve uniqueness of object descriptors.

Bob Stewart objects to the exception for vendors, arguing that, since a
management station must cope with all MIBs including vendor MIBs, it
cannot take advantage of the uniqueness property.  So, why make the
restriction at all?

Robert Snyder said that vendors could not in practice avoid name
collisions with all standard MIBs, past or future, or all MIBs from
other vendors.  Mark Kepke echoed this sentiment and pointed out that,
in large companies, vendors may not even be able to avoid collisions
across the MIBs of a single enterprise.

The Group agreed that the baseline text should require that object
descriptors be unique across all standard MIBs and that vendor MIBs
should not be addressed.

The Group agreed that the editor will propose text that encourages
vendor MIBs to conform to the same rules that constrain standard MIBs.

As a result of this discussion, the Group seemed to agree that object
descriptors are not an essential part of a MIB object definition and may
be altered from time to time for convenience without deprecating the
associated MIB object.  Bob Stewart took an action item to poll the
mailing list for opinions on this, changing names in enumerations, and
adding to enumerations.

At this point, it was noon, and the Group broke for lunch.

When the Group resumed at 13:30, Dave Perkins continued his presentation
of proposed changes to the baseline SMI document.

1) The OBJECT-TYPE macro needs to be replaced by two macros.  The first
is to be used only for ``leaf objects'' or ``management information
objects''.  The second is to be used to define the two grouping objects
which have been called ``tables'' and ``rows''.


                                  10





2) The following is the suggested replacement for the ``OBJECT-TYPE''
macro to define management information objects:    actual MACRO was here


3) The following is the suggested replacement for the ``OBJECT-TYPE''
macro to define table and row objects:    actual MACRO was here

Dave presented Items (1)-(3) in the Specific Comments section of his
list.  The thrust of these changes was to use a new macro for the
definition of conceptual rows in the MIB and to remove some of the more
``tabular'' aspects of the current OBJECT macro as they would be replace
by this new notation.

Peter Wilson objected to these changes because the cost of rewriting
parsers is not acceptable when the benefits of the new notation are not
clear.

Dave said that the benefit of this approach is that it precludes
mistakes in MIB writing that he has observed in his compiler work (e.g.,
mismatches between the types in a SEQUENCE grouping and the the types in
the corresponding object definition).

Peter and Marshall argued that the Group should reject this change:
because of our need for widespread MIB objects, we should want to
minimize (a) the cost of upgrading MIB compilers from V1 to V2 and (b)
the cost of upgrading V1 MIBs to V2 (although it had been stated earlier
in the day that upgrading of MIBs was neither necessary nor desirable if
done independently of other factors in the MIB lifecycle).

The Group agreed that the proposed changes were not necessary.

Dave Perkin proposed a change to the handling of DEFVALs described at
the end of Item (2) in the Specific Comments section of his list of
proposals.  This change would permit a more readable way of expressing
DEFVAL values whose type is defined by a Textual Convention.

Bob Stewart asked if the Group considered itself restricted to the
expressiveness of ASN.1 to satisfy its needs?

The Group provisionally agreed to this proposal, provided that Dave can
find a legal ASN.1 notation for accomplishing it.

28) The replacement for the OBJECT-TYPE macro has a replacement for the
allowed values in the DEFVAL clause.  The change is to accomplish the
following:  * OIDs should be restricted to a name.  The curly bracket
syntax (ie ```` ...  ''')  should not be allowed.  This would restrict
the values to the names of defined OIDs.  * The replacement (if valid
ASN.1) solves the problem of constant values like IP addresses that
can't be expressed in ASN.1.

The Group agreed to Item 28 on Dave's list.

Dave proposed that the MaxPart and AvailPart of the macro defined in
Item 3 on his list be added to the OBJECT macro in the baseline

                                  11





documents.  The intended usage of these clauses is to identify related
MIB objects whose value indicates the location of available ``slots'' in
a MIB table whose implementation may be a memory array.

After some discussion, it was suggested that, instead of using multiple
objects to indicate the ``available entry,'' a single object with OID
syntax should be used.

Steve Waldbusser commented that the ``RMON polka'' is not an expensive
'' strategy and solves a superset of the problem solved by this
mechanism.  He elaborated on the relevance of the available entry
problem to small tables that must be packed (owing to implementation as
memory arrays).

Bob proposed that the max entry, available entry, and num entry clauses
are essentially aids for management stations and should be dealt with in
that context (i.e., not in this Working Group).  The G roup agreed with
this suggestion and the aforementioned clauses will not be included in
the documents.

At this point, the chair began the identification of residual issues and
discussion of future schedule and meetings.

Bob said that, in order to encourage people to air proposals early, he
would promise on the mailing list that proposals posted by Monday, 9
November would be assured time for discussion at the November meeting,
while others might only be considered schedule permitting.  The Group
generally approved of this plan.

Bob emphasized the need for doing ``homework'' before the next meeting.
An interim meeting date was set for 14 December in Atlanta.  This date
will only be used if the Group needs it.

Marshall said that new Internet Draft documents reflecting the
discussions at this meeting would be posted by Thursday.

The Group agreed that its work should be completed in December.  If work
can not be completed at the Washington IETF, the Group will hold a
meeting at Georgia Tech in Atlanta.  The suggested date for this meeting
was 14 December.

Bob proposed that the deferred discussion on party proliferation be
referred entirely to the SNMP Security Working Group.  Keith accepted
and the Group did not object.

The meeting closed with a brief review of the DISPLAY-HINT discussion in
particular and the more general question of whether the Group should
focus on technology that is primarily an aid to managers or leave that
for future work.  Chuck raised the question of whether display hint
should be broken into two parts:  (1) representation on the wire and (2)
display format hint for a user interface.  The consensus was that the
current text would stand for now pending any future proposals on this
question.


                                  12





The meeting adjourned at 4:00 PM.

#####

Deferred Issues List

1) Should Textual Conventions be part of the SMI?

2) Is the Textual Conventions macro consistent with ASN.1 subtyping?

3) Further work on the DISPLAY-HINT clause is needed.

4) Conformance issues need further definition, esp.  with respect to
interactions between SNMP V1 and SNMP V2.

5) Restart Domain and Entity Domain require further discussion.

6) Ommision of readOnly(4).  Action item (Chuck):  post an email query
to the relevant mailing lists asking for information about the use of
readOnly in deployed implementations.

7) Can MIB objects be in zero compliance groups?  I.e., can there be
``dangling objects''?  Action (Bob):  report on this issue.

8) Are the row manipulation mechanisms adequate to address scenarios in
which there may be significant time delay between an SNMP row
manipulation and the alteration of the underlying management state?  Is
operation in such scenarios a requirement?  Action (Tracy):  propose an
answer to these questions.

#####

Proposed Changes to SNMP Version 2 Documents:  October 5-6, 1992

A Contribution to the IETF SNMP2 Working Group Jeff Case, Keith
McCloghrie, Marshall Rose, Steve Waldbusser



 1.  All documents:  throughout
     Lose the term SMP

 2.  Transport Mappings:  throughout
     Document should use consistent naming of domains,
     e.g., smpUDPdomain, smpOSIclnsDomain, smpDDPDomain

     all should be changed to Domain

 3.  Transport Mappings:  page 5
     In comment prior to SmpOSIAddress, change ``string or (up to'' to
     ``string of (up to''.

 4.  Transport Mappings:  page 12
     Add new sentence at end of Section 8.1:

                                  13





     Because the address associated with this transport mapping is internal
     to the agent, an SMP entity acting in a manager role cannot directly
     communicate with a party using this transport mapping.  As such,
     communications are accomplished using the partyProxyFor object of a
     party which uses a transport mapping with an externally accessible address.

 5.  Transport Mappings:  page 13
     Add new sentence at end of Section 9.1:
     Because the address associated with this transport mapping is internal
     to the agent, an SMP entity acting in a manager role cannot directly
     communicate with a party using this transport mapping.  As such,
     communications are accomplished using the partyProxyFor object of a
     party which uses a transport mapping with an externally accessible address.

 6.  Transport Mappings:  page 15

     <     These restrictions apply to all aspects of ASN.1 encoding,
     <     both for the protocol data units and the data objects they
     <     contain.

     >     These restrictions apply to all aspects of ASN.1 encoding,
     >     including the message wrappers, protocol data units, and the
     >     data objects they contain.

 7.  Transport Mappings:  page 15
     < (2)  When encoding the value field, the primitive form is used
     <      whenever possible.
     > (2)  When encoding the value field, the primitive form shall be
     >      used for all simple types, i.e., INTEGER, BIT STRING, OCTET
     >      STRING, and OBJECT IDENTIFIER (either IMPLICIT or explicit).
     >      The constructed form of encoding shall be used only for
     >      structured types, i.e., a SEQUENCE or an implicit SEQUENCE.

 8.  Transport Mappings:  page 16
     Example needs to include a length field which is not expressed in the
     minimum number of bytes.

 9.  Transport Mappings:  page 16
     Remove extraneous comma in mapping example: ``NULL } },`` to ``NULL } }''

10.  PROTO:  page 6
     Start a new paragraph after the first sentence in (2).  (The paragraph
     starts with ``The former is...''

11.  PROTO:  page 10
     Remove readOnly(4).

12.  PROTO:  page 21
     Delete the clarifying ``implementation strategies'' paragraph from the
     description of the awesome getBulk operator ... it only caused confusion.

13.  PROTO:  page 24
     Add at the end of third paragraph in Section 5.2.4:
     A compliant SMP entity acting in the manager role must be able to

                                  14





     properly receive and handle a Response-PDU with an error-status field equal
     to noSuchName(2) or badValue(3).  (See Section 4.1.2 of [coex].)

14.  SMI: (distributed)
     Every MIB document (including trap documents), every compliance document,
     and every capabilities document must have a required preamble title block
     which describes the version number, last revision date, originating
     organization, and contact information.

15.  SMI:  pages 6 and 23
     Clarify the meaning of mandatory in the STATUS clause, perhaps by changing
     it to a word which parallels ``obsolete'' and ``deprecated'' and which ref*
 *lects
     the role shift of the STATUS clause.  Candidates include ``current'',
     and ``effacious''.

16.  SMI:  page 23
Add the following parenthetical clarification:

          If any columnar object in a conceptual row has ``read-create''
          as its maximal level of access, then no other columnar object
          of the same conceptual row may have a maximal access of
          ``read-write''.  (Note that ``read-create'' is a superset of
  ``read-write'').

17.  SMI:  page 25

           accessible''.  However, a conceptual row must contain at least
           one columnar object which is not an auxiliary object (i.e.,
           the value of the MAX-ACCESS clause for such an object is
           something other than ``not-accessible'').

     The last line should be ``read-only'' or ``read-create'', i.e., it can't be
     ``read-write''.

18.  SMI:  page 27
     Add new paragraph before last paragraph at end of Section 4.8:
     For example, a MIB designer might wish to define additional columns in an
     enterprise MIB which logically extend a conceptual row defined in a
     standard MIB.  The standard MIB definition of the conceptual row would
     include the INDEX clause and the enterprise MIB would contain the
     definition of a conceptual row using the AUGMENTS clause.

19.  SMI:  page 27
     <    The value of an instance of the named object is the (exact or
     <    approximate) number of conceptual rows.
     >    The value of the one and only instance of the named object is the
     >    (exact or approximate) number of conceptual rows.

20.  SMI:  page 27

     <    The DEFVAL clause, which need not be present, defines an
     <    acceptable default value which may be used when an object
     <    instance is created at the discretion of the SMP entity acting
     <    in an agent role.

                                  15






     >    The DEFVAL clause, which need not be present, defines an
     >    acceptable default value which may be used at the discretion
     >    of an SMP entity acting in an agent role when an object instance
     >    is created.

21.  SMI:  page 32
     Add new sentence end of Section 5.1
     An object may be named in zero, one, or many groups.

22.  SMI:  page 49

     <               SYNTAX       INTEGER { maxttl(255) }
     >               SYNTAX       INTEGER { (255..255) }

23.  MIB document page 20

               DESCRIPTION
                      ``The number of traps which have been sent to a
                      particular SMP party, since the last
                      initialization of the SMP protocol entity, or the
                      creation of the SMP party, which ever occurred
                      most recently.''
               ::= { smpTrapEntry 1 }

     which ever --> whichever

24.  MIB 2 and MIB.

     Deprecate the SNMP subtree.  Delete the entire smpInOut group.  Replace
     them with the following new variables in two groups as follows (all are
     similar to other variables previously defined):
        Group 1:  (mandatory for all entities)
snmpInASNParseErrors
snmpEnableAuthenTraps
snmpInUnknownSrcParties
snmpInUnknownDstParties
snmpInBadAuths
snmpInNotInLifetimes
snmpInWrongDigestValues
snmpInBadOperations
snmpInSilentDrops
Group 2:  (optional, only for entities which support SNMP Version 1)
snmpInBadVersions
snmpInBadCommunityNames
snmpInBadCommunityUses

25.  M2M:
     Page 7:  Remove ObjectName from IMPORTS clause
     Page 7:  Add InstancePointer to IMPORTS clause for SMP-TC
     Page 10: (2x)  Change ObjectName --> InstancePointer

26.  Coex:  page 9
     <               `badValue', or `readOnly', the proxy agent must not

                                  16





     >               or `badValue', the proxy agent must not

27.  Textual Conventions:  page 8 in enumerations and associated text
     <          underCreation(1)
     <          underDestruction(2)
     <          underModification(3)
     <          active(4)

     >          active(1)
     >          underConstruction(2)
     >          underModification(3)
     >          underDestruction(4)



#####

Attendees

Steve Alexander          [e-mail]
Uri Blumenthal           [e-mail]
Jeff Case                [e-mail]
Tracy Cox                [e-mail]
James Davin              [e-mail]
Michael Davison          [e-mail]
Taso Devetzis            [e-mail]
Gary Haney               [e-mail]
Matthew Hecht            [e-mail]
Susan Hicks              [e-mail]
Satish Joshi             [e-mail]
Mark Kepke               [e-mail]
Kenneth Key              [e-mail]
Michael Kornegay         [e-mail]
Deirdre Kostick          [e-mail]
Cheryl Krupczak          [e-mail]
Robert Lushbaugh         [e-mail]
Keith McCloghrie         [e-mail]
David Minnich            [e-mail]
David Perkins            [e-mail]
Shawn Routhier           [e-mail]
Marshall Rose            [e-mail]
Jon Saperia              [e-mail]
Robert Snyder            [e-mail]
Bob Stewart              [e-mail]
Maurice Turcotte         [e-mail]
Steven Waldbusser        [e-mail]
Bert Wijnen              [e-mail]
Peter Will               [e-mail]
Steven Wong              [e-mail]
Chris Young              [e-mail]
Kiho Yum                 [e-mail]



                                  17